Method and apparatus for handling exceptions during binding to native code

ABSTRACT

A method of handling exceptions during native binding under program code conversion from subject code ( 17 ) executable by a subject computing architecture to target code ( 21 ) executable by a target computing architecture. Performing native binding executes a portion of native code ( 28 ) in place of translating a portion of the subject code ( 17 ) into the target code ( 21 ). When an exception occurs during the portion of native code ( 28 ), the method comprises saving a target state (T′) which represents a current point of execution in the target computing architecture for the portion of native code ( 28 ), and creating a subject state (S′) which represents an emulated point of execution in the subject computing architecture. The exception is handled through a subject exception handler ( 170, 170 ′) with reference to the subject state (S′), such that, upon resuming execution from the exception using the provided subject state (S′), the saved target state (T′) is restored to resume execution in the section of portion of native code ( 28 ). In one embodiment, the subject state (S′) links to the saved target state (T′) through a recovery unit ( 192 ).

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims benefit of the following Patent Application:

U.K. Patent Application No. GB0612149.5, filed Jun. 20, 2006, which ishereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to the field of computers andcomputer software and, more particularly, to program code conversionmethods and apparatus useful, for example, in code translators,emulators and accelerators which convert program code.

BACKGROUND OF THE INVENTION

In both embedded and non-embedded CPUs, there are predominantInstruction Set Architectures (ISAs) for which large bodies of softwareexist that could be “accelerated” for performance, or “translated” to amyriad of capable processors that could present better cost/performancebenefits, provided that they could transparently access the relevantsoftware. One also finds dominant CPU architectures that are locked intime to their ISA, and cannot evolve in performance or market reach.Such CPUs would benefit from a software-oriented processor coarchitecture.

PCT application WO00/22521 (also published as US2002/0100030A), which isincorporated herein by reference, discloses program code conversionmethods and apparatus to facilitate such acceleration, translation andco-architecture capabilities as may be employed in embodiments of thepresent invention.

Performing program code conversion brings overheads in the conversionprocess, compared with native execution of a subject program on asubject processor. A subject program usually consists of multiple unitsof subject code, including a subject executable and a number of subjectlibraries, some of which may be proprietary and some of which areprovided as part of the subject operating system. As the subject programruns, control flow passes between these different units of subject codeas function calls are made to the subject libraries. In somecircumstances, native versions of certain subject libraries may beavailable on the target architecture.

PCT application WO2005/008478 (also published as US2005/0015781A), whichis incorporated herein by reference, discloses a native bindingtechnique for inserting calls to native functions during translation ofsubject code to target code, such that function calls in the subjectprogram to subject code functions are replaced in target code with callsto native equivalents of the same functions. This avoids the overhead oftranslating the subject versions of those functions. In addition, thenative version may be a much more efficient implementation of the samefunctionality, as the native version can better exploit architecturalfeatures of the target architecture which may not be available on thesubject architecture.

Although the native binding technique is very useful, the inventors havenow identified in that a difficulty arises in relation to exceptionhandling. An exception is a condition that changes the normal controlflow in a program. An exception indicates that a condition has occurredsomewhere within the system that requires the attention of theprocessor, and the exception usually needs to be handled beforeprocessing can continue. Exceptions can be subdivided into variousdifferent types such as interrupts, faults, traps or aborts. Theterminology varies between different architectures, and particular typesor categories of exceptions may be unique to particular architectures.

Undertaking the native binding mechanism reduces overhead in thetranslation process, such as the work of maintaining an accurate subjectstate. However, the execution of such native code also bringsdifficulties such as in the reporting of a subject state to a subjectexception handler. Further, difficulties have now been identified inrelation to resuming execution of the subject program after theexception has been handled, and particularly where it is desired toresume execution of the native code.

SUMMARY OF THE INVENTION

According to the present invention there is provided an apparatus andmethod as set forth in the appended claims. Preferred features of theinvention will be apparent from the dependent claims, and thedescription which follows.

The following is a summary of various aspects and advantages realizableaccording to embodiments of the invention. It is provided as anintroduction to assist those skilled in the art to more rapidlyassimilate the detailed design discussion that ensues and does not andis not intended in any way to limit the scope of the claims that areappended hereto.

In particular, the inventors have developed methods directed at programcode conversion, which are particularly useful in connection with arun-time translator that provides dynamic binary translation of subjectprogram code into target code.

In one aspect of the present invention there is provided a method ofhandling exceptions during native binding under program code conversionfrom subject code executable by a subject computing architecture totarget code executable by a target computing architecture. Performingnative binding executes a portion of native code, usually in place oftranslating a portion of the subject code into the target code. When anexception occurs during execution of the native bound code, the methodcomprises saving a target state which represents a current point ofexecution in the target computing architecture for the native boundcode, providing a subject state, and handling the exception withreference to the subject state, such that, upon resuming execution fromthe exception using the subject state, the saved target state isrestored to resume execution of the native bound code.

In the example embodiments, the subject state represents a point ofexecution in the subject computing architecture, which is emulated bythe target computing platform. Particularly, the subject state mayinclude a stack pointer to a subject stack data structure in the memoryof the target computing platform used to emulate a procedure stack (orcontrol stack) of the subject architecture. Conveniently, the targetstate is saved to the subject stack, such that the subject stack pointerlinks to the stored target state. Further, in the example embodiments,execution of the native bound code uses the subject stack. Furtherstill, in example embodiments the subject state includes a modifiedprogram counter which is used to redirect execution control whenreturning from handling the exception. In some embodiments, a recoveryroutine is performed which links from the subject state to the savedtarget state.

The present invention also extends to a translator apparatus arranged toperform the embodiments of the invention discussed herein. Also, thepresent invention extends to computer-readable storage medium havingrecorded thereon instructions which may be implemented by a computer toperform any of the methods defined herein.

At least some embodiments of the invention may be constructed, partiallyor wholly, using dedicated hardware. Optionally, the target computingplatform is provided as a function-specific dedicated translatorapparatus.

Terms such as ‘module’ or ‘unit’ used herein may include, but are notlimited to, a hardware device, such as a Field Programmable Gate Array(FPGA) or Application Specific Integrated Circuit (ASIC), which performscertain tasks. Alternatively, elements of the invention may beconfigured to reside on an addressable storage medium and be configuredto execute on one or more processors. Thus, functional elements of theinvention may in some embodiments include, by way of example,components, such as software components, object-oriented softwarecomponents, class components and task components, processes, functions,attributes, procedures, subroutines, segments of program code, drivers,firmware, microcode, circuitry, data, databases, data structures,tables, arrays, and variables. Further, although the preferredembodiments have been described with reference to the components,modules and units discussed below, such functional elements may becombined into fewer elements or separated into additional elements.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate presently preferredimplementations and are described as follows:

FIG. 1 is a block diagram illustrative of apparatus wherein embodimentsof the invention find application;

FIG. 2 is a schematic diagram illustrating a native binding mechanism asemployed in embodiments of the invention;

FIG. 3 is a schematic diagram showing components which are employed forthe handling of exceptions by example embodiments of the presentinvention;

FIG. 4 is a schematic diagram showing execution in a subject computingplatform when calling a subject library function and when handling anexception during execution of the library function;

FIG. 5 is a schematic diagram showing execution in a target computingplatform when performing native binding and when handling an exceptionin native bound code, as employed in embodiments of the presentinvention;

FIG. 6 is a schematic diagram showing a flow of execution control whenhandling an exception in native bound code, as employed in embodimentsof the present invention;

FIG. 7 is a schematic diagram of a portion of the memory of the targetcomputing platform; and

FIG. 8 is a schematic flow diagram illustrating a method of handlingexceptions for native bound code as employed by example embodiments ofthe present invention.

DETAILED DESCRIPTION

The following description is provided to enable a person skilled in theart to make and use the invention and sets forth the best modescontemplated by the inventors of carrying out their invention. Variousmodifications, however, will remain readily apparent to those skilled inthe art, since the general principles of the present invention have beendefined herein specifically to provide an improved program codeconversion method and apparatus.

FIG. 1 gives an overview of a system and environment where the exampleembodiments of the present invention may find application, in order tointroduce the units, components and elements that will be discussed inmore detail below. Referring to FIG. 1, a subject program 17 is intendedto execute on a subject computing platform 1 having at least one subjectprocessor 3. However, a target computing platform 10 is instead used toexecute the subject program 17, through a translator unit 19 whichperforms program code conversion. The translator unit 19 performs codeconversion from the subject code 17 to target code 21, such that thetarget code 21 is executable on the target computing platform 10.

As will be familiar to those skilled in the art, the subject processor 3has a set of subject registers 5. A subject memory 8 holds, inter alia,the subject code 17 and a subject operating system 2. Similarly, theexample target computing platform 10 in FIG. 1 comprises a targetprocessor 13 having a plurality of target registers 15, and a memory 18to store a plurality of operational components including a targetoperating system 20, the subject code 17, the translator code 19, andthe translated target code 21. The target computing platform 10 istypically a microprocessor-based computer or other suitable computer.

In one embodiment, the translator code 19 is an emulator to translatesubject code of a subject instruction set architecture (ISA) intotranslated target code of another ISA, with or without optimisations. Inanother embodiment, the translator 19 functions as an accelerator fortranslating subject code into target code, each of the same ISA, byperforming program code optimisations.

The translator code 19 is suitably a compiled version of source codeimplementing the translator, and runs in conjunction with the operatingsystem 20 on the target processor 13. It will be appreciated that thestructure illustrated in FIG. 1 is exemplary only and that, for example,embodiments of the invention may be implemented within or beneath theoperating system 20 of the target platform. The subject code 17,translator code 19, operating system 20, and storage mechanisms of thememory 18 may be any of a wide variety of types, as known to thoseskilled in the art.

In the example apparatus according to FIG. 1, program code conversion isperformed dynamically, at run-time, to execute on the targetarchitecture 10 while the target code 21 is running. That is, thetranslator 19 runs inline with the translated target code 21. Runningthe subject program 17 through the translator 19 involves two differenttypes of code that execute in an interleaved manner: the translator code19; and the target code 21. Hence, the target code 21 is generated bythe translator code 19, throughout run-time, based on the stored subjectcode 17 of the program being translated.

In one embodiment, the translator unit 19 emulates relevant portions ofthe subject architecture 1 such as the subject processor 3 andparticularly the subject registers 5, whilst actually executing thesubject program 17 as target code 21 on the target processor 13. In thepreferred embodiment, at least one global register store 27 is provided(also referred to as the subject register bank 27 or abstract registerbank 27). In a multiprocessor environment, optionally more than oneabstract register bank 27 is provided according to the architecture ofthe subject processor. A representation of a subject state is providedby components of the translator 19 and the target code 21. That is, thetranslator 19 stores the subject state in a variety of explicitprogramming language devices such as variables and/or objects. Thetranslated target code 21, by comparison, provides subject processorstate implicitly in the target registers 15 and in memory locations 18,which are manipulated by the target instructions of the target code 21.For example, a low-level representation of the global register store 27is simply a region of allocated memory. In the source code of thetranslator 19, however, the global register store 27 is a data array oran object which can be accessed and manipulated at a higher level.

The term “basic block” will be familiar to those skilled in the art. Abasic block is a section of code with exactly one entry point andexactly one exit point, which limits the block code to a single controlpath. For this reason, basic blocks are a useful fundamental unit ofcontrol flow. Suitably, the translator 19 divides the subject code 17into a plurality of basic blocks, where each basic block is a sequentialset of instructions between a first instruction at a single entry pointand a last instruction at a single exit point (such as a jump, call orbranch instruction). The translator 19 may select just one of thesebasic blocks (block mode) or select a group of the basic blocks (groupblock mode). A group block suitably comprises two or more basic blockswhich are to be treated together as a single unit. Further, thetranslator may form iso blocks representing the same basic block ofsubject code but under different entry conditions.

In the preferred embodiments, trees of Intermediate Representation (IR)are generated based on a subject instruction sequence, as part of theprocess of generating the target code 21 from the original subjectprogram 17. IR trees are abstract representations of the expressionscalculated and operations performed by the subject program. Later, thetarget code 21 is generated based on the IR trees. Collections of IRnodes are actually directed acyclic graphs (DAFs), but are referred tocolloquially as “trees”.

As those skilled in the art may appreciate, in one embodiment thetranslator 19 is implemented using an object-oriented programminglanguage such as C++. For example, an IR node is implemented as a C++object, and references to other nodes are implemented as C++referencesto the C++ objects corresponding to those other nodes. An IR tree istherefore implemented as a collection of IR node objects, containingvarious references to each other.

Further, in the embodiment under discussion, IR generation uses a set ofabstract register definitions which correspond to specific features ofthe subject architecture upon which the subject program 17 is intendedto run. For example, there is a unique abstract register definition foreach physical register on the subject architecture (i.e., the subjectregisters 5 of FIG. 1). As such, abstract register definitions in thetranslator may be implemented as a C++object which contains a referenceto an IR node object (i.e., an IR tree). The aggregate of all IR treesreferred to by the set of abstract register definitions is referred toas the working IR forest (“forest” because it contains multiple abstractregister roots, each of which refers to an IR tree). These IR trees andother processes suitably form part of the translator 19.

Native Binding

FIG. 1 further shows native code 28 in the memory 18 of the targetarchitecture 10. There is a distinction between the target code 21,which results from the run-time translation of the subject code 17, andthe native code 28, which is written or compiled directly for the targetarchitecture. Native code 28 is generated external to the translator 19,meaning that the translator 19 does not dynamically generate the nativecode 28 and the translator 19 does have an opportunity to modify oroptimize the native code 28.

FIG. 2 is a more detailed schematic diagram illustrating a nativebinding mechanism as employed in embodiments of the present invention.

Native binding is implemented by the translator 19 when it detects thatthe subject program's flow of control enters a section of subject code17, such as a subject library, for which a native version of the subjectcode exists. Rather than translating the subject code, the translator 19instead causes the equivalent native code 28 to be executed on thetarget processor 13. In example embodiments, the translator 19 bindsgenerated target code 21 to the native code 28 using a definedinterface, such as native code or target code call stubs, as discussedin more detail in WO2005/008478 (and US2005/0015781A) referenced above.

The subject program 17 usually includes one or more subject executablefiles 17 a which are translated into target code 21 a. The subjectexecutable 17 a may in turn refer to and make use of a number of subjectlibraries including proprietary libraries and/or system libraries. Twoexample library functions 17 b, 17 c are illustrated. The translator 19uses native binding to replace calls to certain of the subject libraryfunctions with calls to equivalent functions in native librariesprovided in the native code 28. In this example, the translator 19 hastranslated a first library function A into target code 21 b, whereas asecond library function B is native bound to a native library functionin native code 28. These native libraries are typically part of thetarget operating system 20, but may also be provided to the targetsystem along with the translator 19.

As an illustrative example, the translator 19 is arranged to perform aMIPS to x86 translation. Here, the x86 target system library “libc”defines an advanced native memcpy( ) (memory copy) routine that takesadvantage of SSE2 vector operations to perform extremely fast bytecopies. Using native binding, calls to a subject memcpy function in theMIPS subject code are bound to the native memcpy( ). This eliminates thecost of translating the subject (MIPS) version of the memcpy( )function. In addition, the native (×86) version of the memcpy( ) isadapted to the intricacies of the native hardware, and can achieve thefunction's desired effect in the most efficient way for that hardware.

Native binding is primarily applicable to library functions, but mayalso be implemented for any well-defined section of subject code forwhich a native code equivalent is available in the target architecture.That is, in addition to target system library calls, native binding maybe used for more arbitrary code substitution, such as substituting anatively compiled version of a non-library function. Furthermore, nativebinding may be used to implement subject system calls on a nativearchitecture, by replacing all calls to subject system functions withsubstitute native functions that either implement the same functionalityas the calls to subject system functions or act as call stubs aroundtarget system calls. Native binding may also be applied at arbitrarysubject code locations, beyond function call sites, to allow arbitrarycode sequences (in either target code or native code) and/or functioncalls to be inserted or substituted at any well-defined point in thesubject program.

Exception Handling

FIG. 3 is a more detailed schematic diagram of the target computingplatform 10 of FIG. 1, showing components which are employed relevant tothe handling of exceptions as performed by an example embodiment of thepresent invention.

An exception may be generated (“raised”) by hardware or by software.Hardware exceptions include signals such as resets, interrupts, orsignals from a memory management unit. As examples, exceptions may begenerated by an arithmetic logic unit or floating-point unit fornumerical errors such as divide-by-zero, for overflow or underflow, orfor instruction decoding errors such as privileged, reserved, trap orundefined instructions. Software exceptions occur in many differentforms across various software programs and could be applied to any kindof error checking which alters the normal behaviour of the program. Asan illustrative example, an instruction in the subject code causes asoftware exception to be reported if the value of one register isgreater than the value of a second register.

Typically, one or more subject exception handlers 170 are provided(registered) to handle exceptions which occur during execution of thesubject program 17. An exception handler is special code which is calledupon when an exception occurs during the execution of a program. If thesubject program does not provide a handler for a given exception, then adefault system exception handler may be called. The exception handlerwill usually try to take corrective action and resume execution, orabort running of the subject program and return an error indication. Inthe context of program code conversion, it is desirable to accuratelymodel, on the target system, the behaviour of the subject exceptionhandler(s).

Exception signals are a common mechanism for raising exceptions on manyoperating systems. The POSIX standard, which is adhered to by manyoperating systems, particularly Unix-like systems, specifies how thismechanism should behave so that exception signals are broadly similaracross many systems. The most common events that trigger exceptions arewhen a process implemented by a program tries to access an unmappedmemory region or manipulate a memory region for which it does not havethe correct permissions. Other common events that trigger exceptionsignals are the receipt of a signal sent from another process, theexecution by a process of an instruction that the process does not havethe privilege level to execute, or an I/O event in the hardware.

FIG. 3 shows a set of subject exception handlers 170, which may includespecific subject exception handlers that are specific to a particulartype of exception and one or more default system exception handlers tobe employed where a specific exception handler is not registered.Conveniently, the subject exception handlers 170 are made available onthe target platform as part of the subject code 17.

The translator 19 also provides a corresponding set of translatedsubject exception handlers 170′ in target code 21 to execute on thetarget processor 13, which emulate the subject exception handlers 170.In particular embodiments, the subject exception handlers 170 aredynamically translated into executable target code versions when needed.It will be understood that reference to a subject exception handler 170in the following description includes, where appropriate, a reference tothe translated target code version of the subject exception handler.

FIG. 4 is a schematic diagram showing execution in the subject computingplatform when calling a subject library function and when handling anexception during execution of the library function.

When an exception occurs, a current subject state is stored to apredetermined location (e.g. to a stack) and execution control passes tothe appropriate subject exception handler 170. The subject exceptionhandler 170 will often use this stored subject state information inorder to handle the exception. Also, if the exception handler sodetermines, the subject state is used to resume execution of the subjectprogram, either at the same point as where the exception occurred, or atsome other point in the subject program. The subject exception handlermay, as part of handling the exception, alter the stored subject state,such as by altering a stored program counter. Hence, in the context ofprogram code conversion, it is desirable to accurately follow theexpected behaviour of the subject exception handler 170.

As will be familiar to persons skilled in the art, in architectureswhich use a stack for procedure calls, a subject stack 81 storesinformation about the active subroutines or library functions which havebeen called by the subject program. Usually, the subject stack 81 isprovided in the memory 8 of the subject platform 1, and many processorsprovide special hardware to manipulate such stack data structures inmemory. The main role of the stack 81 is to keep track of the point towhich each active function should return when it finishes executing,although the stack may also be used for other purposes such as to passfunction parameters and results, and to store local data. Typically,each function call puts linking information on the stack, including areturn address. This kind of stack is also known as an execution stack,control stack, or function stack. Usually, one stack is associated witheach running program or with each task of a process. The exact detailsof the stack depend upon many factors including, for example, thesubject hardware, the subject operating system, and the instruction setarchitecture of the subject platform.

In FIG. 4, the subject state S includes information such as the contentof at least some of the subject registers. In particular, the subjectstate S may include information such as current values of a subjectstack pointer (SP_S) and a subject program counter (PC_S), amongstothers. When the caller subject program 17 a calls a subject libraryfunction 17 b, the subject state S is stored by pushing the contents ofthe subject registers to the subject stack 81, and the subject stackpointer SP_S is updated to point to the top of the subject stack 81.During execution of the called library function 17 b, local data may bestored on the subject stack 81 and a new subject state S′ is formed.When an exception occurs, the new subject state S′ is stored on thestack 81, and execution passes to the subject execution handler 170.After handling the exception, the subject platform will be in a thirdstate S″. In this example, the second stored state S′ is recovered fromthe stack after handling the exception, and execution resumes at thepoint in the subject library function 17 b where the exception occurred.Later, the first stored state S is recovered when execution returns fromthe library function 17 b to the caller program 17 a.

FIG. 5 is a schematic diagram showing a state of execution in the targetcomputing platform when performing native binding and when handling anexception in native bound code, as employed in embodiments of thepresent invention. In particular, FIG. 5 illustrates an exampleembodiment of the present invention which allows a useful subject stateS′ to be reported to the subject exception handler 170, and also allowsexecution to resume in the native bound code 28.

For program code conversion as discussed herein, the translator 19provides elements on the target platform 10 which are, in general terms,functionally equivalent to those on the subject platform 1. In thisexample, the translator 19 provides a representation of the subjectstack 81 in the target memory 18, and represents the subject registers 5using the abstract register bank 27. Hence, the translator 19 is able toemulate all of the structures shown in FIG. 4 when the subject code 17 acalls the subject library function 17 b and when a exception is handledin the subject exception handler 170. However, when performing nativebinding, the translator 19 no longer has close control over the nativebound code 28 and the translator 19 cannot maintain a subject state S′which remains precisely equivalent to the subject state during executionof the subject library function 17 c on the subject platform. However,the embodiments discussed herein allow the translator 19 to provide anappropriate equivalent of the second subject state S′ to the subjectexception handler 170. Further, the embodiments discussed herein allowexecution control to return to the native bound code 28 after theexception has been handled.

In FIG. 5, the target platform 10 has a target state T which representsinformation such as a target program counter and a target stack pointer,and the current state of the target registers 15 in the target processor13. Initially, the target state T reflects the execution of target code21 produced by the translator 19 from the caller subject program 17 a.Execution of the target code 21 causes a subject state S to be providedon the target platform, as discussed above.

The native binding technique is employed to execute a native codelibrary function B, and the first target state T evolves to a secondtarget state T′ during execution of the native bound code 28. When anexception occurs during execution of the native bound code 28, anexception signal is raised (i.e. by the target OS 20) and passed to theregistered exception handler. As part of handling the exception, thetarget state T′ is saved to an appropriate storage location in thetarget system, in this case to the subject stack 81. This second targetstate T′ represents a current point of execution in the target processor13 for the native bound code 28, at the point when the exceptionoccurred. Also, an exception handler unit 191 of the translator 19creates and stores a subject state S′, before passing execution controlto the subject exception handler 170. The subject execution handler 170is invoked to handle the exception with reference to the created subjectstate S′. Here, the second subject state S′ comprises at least a subjectstack pointer (SP_S) pointing to the subject stack 81 above the savedtarget state T′. Conveniently, the previously saved subject state S isused as a foundation for the second subject state S′, with amodification to include the required new value of the subject stackpointer (SP_S).

Execution of the subject exception handler 170 results in a thirdsubject state S″ and a third target state T″ (due to the work done onthe target platform to handle the exception). However, the subjectexception handler 170 is now able to refer to the saved subject state S′in order to resume execution in the native bound code 28 at the pointwhere the exception occurred. That is, the saved subject state S′ ownsthe saved target state T′ and resuming execution of the subject code atthe saved subject state S′ resumes execution of the native bound code28.

It is useful to note that, in this illustrated embodiment, the first andthird target states T and T″ refer to execution of the target code 21produced by the translator 19 from the relevant subject code 17. In thisembodiment, execution of the target code 21 uses a target stack (notshown) also provided in the memory of the target platform separatelyfrom the subject stack 81. By contrast, the second target state T′refers to execution of the native code 28 using the subject stack 81.Hence, the second target state T′ is shown to include a stack pointer(here illustrated with an arrow) which points to the subject stack 81,whilst the first and third target states do not.

As shown in FIG. 5, the example embodiments of the present invention usethe subject stack 81 for execution of the native bound code 28. Asdiscussed above, the subject stack 81 is a designated area of the memory18, which the translator 19 manages on behalf of the subject code 17 aspart of the subject code to target code translation. Using the subjectstack 81 for execution of the native code 28 prevents the native contextT′ being lost as a result of servicing an exception during execution ofthat native bound code. In particular, the subject stack 81 is preservedwhen executing the translated version of the subject exception handler170. As a further advantage, using the subject stack 81 for nativebinding execution allows environment switches in the subject code 17 tobe dealt with transparently, such as by executing library calls similarto a “longjmp” function. A longjmp function restores a subject stack andsubject state previously saved by calling a setjmp. This provides a wayto execute a non-local “go to” type instruction and is typically used topass execution to recovery code from the subject exception handler 170.Therefore, by using the subject stack 81 for native binding, resourcescan be reclaimed transparently if the subject code 17 calls a longjmp.As part of the translation of the subject longjmp function, thetranslated code resets the subject stack pointer SP_S to reclaim stackspace allocated by the native binding mechanism.

In some alternate embodiments of the present invention, execution of thenative code 28 may employ a different stack elsewhere in the memory 18of the target platform 10, such as a stack of the translator 19(translator stack) or a separately allocated native stack (not shown),instead of the subject stack 81.

FIG. 6 shows a flow of execution control when handling an exception innative bound code, as employed in embodiments of the present invention.

In FIG. 6, the caller subject code 17 a (executing as caller target code21 a) calls into the native bound code 28 and an appropriate subjectstate S is saved on the subject stack 81 to allow a return into thecaller target code 21 a. An exception occurs during the native boundcode 28 which, as discussed above, provides a target state T′. Thenative binding mechanism returns control to the translator 19 and thetarget state T′ is saved.

As discussed above, the translator 19 generates the second subject stateS′. In this aspect of the invention, the second subject state includes,inter alia, at least a subject program counter PC_S′ which is speciallymodified by the translator 19. In particular, the specially modifiedsubject program counter value PC_S′ passed to the subject exceptionhandler 170 does not correspond to a program address of the subjectprogram 17. However, the subject exception handler 170 (executing astranslated subject exception handler 170′) may use this subject programcounter PC_S′ as a return address when attempting to restart executionat the point where the exception occurred.

In a first example embodiment as shown in FIG. 6, the translator 19includes a recovery unit 192 which acts to recover the target state T′and resume execution in the native bound code. In one embodiment, therecovery unit is form by providing a reserved location 171 (see FIG. 7),such as a memory page within the translator's address space, which thetranslator 19 will treat as a portion of subject code 17. Thus, when thetranslated subject exception handler 170′ attempts to pass control tothe program location identified by the specially modified subjectprogram counter PC_S′, the translator 19 is directed to the reservedlocation 171. In this first embodiment, the reserved location 171contains subject code instructions which, when translated and executedas target code, cause the target state T′ to be recovered such that thenative bound code 28 resumes execution. Here, restoring the target stateT′ suitably includes filling the target registers with the saved versionof their previous contents, such as popping these values from thesubject stack 81.

In a second example embodiment as also illustrated by FIG. 6, thereserved location 171 contains special case instructions which do notfall within the instruction set of the subject architecture. Instead,the translator 19 recognises these special case instructions and inresponse executes a recovery routine to recover the stored target stateT′ and allow the native code 28 to resume. Here, the recovery routine issuitably provided as part of the translator code 19.

In another example embodiment, the program counter PC_S′ passed in thesubject state S′ is a predetermined notional value (such as 0X000000)which does not correspond to a real location in the memory of the targetarchitecture. The translator 19 is configured to recognise this specialprogram counter and, instead of passing control to the identifiedlocation, redirects the flow of execution to execute the recoveryroutine 171 which loads the stored target state T′ and allows the nativecode 28 to resume. This particular embodiment relies on the translator19 to detect when the subject program counter is a given predeterminedvalue and to take a different action.

Referring again to FIGS. 5 and 6, in the example embodiments discussedherein the first subject state S is employed in creating the secondsubject state S′. Suitably, the first subject state S is saved when thenative code 28 is called, and hence the first subject state S isavailable to populate the second subject state S′ when an exceptionoccurs. That is, the old subject state S is copied forward to become thenew subject state S′, except that the program counter PC_S is modifiedto the special value PC_S′, and/or the stack pointer is updated to thenew head of the subject stack 81. This mechanism provides the subjectexception handler 170 with a workable subject state S′ sufficient tohandle the exception. The subject exception handler 170 may, forexample, examine the subject program counter PC_S to determine wherewithin the subject program the exception occurred. The subject handler170 may then determine how to deal with the exception. The subjectexception handler 170 is usually written in a manner which makes someassumptions about the program address space of the subject code program17 and any dynamically allocated memory. However, the subject exceptionhandler 170 usually cannot assume the memory areas where othercomponents of the system, such as library functions, will reside. Wherethe subject program counter PC_S′ reported to the subject exceptionhandler 170 lies outside the address range allocated to the subject code17, the subject exception handler 170 cannot make detailed decisionsbased on the supposed state of the subject platform and will thereforehandle the exception similar to the manner in which it would have beenhandled on the subject platform.

FIG. 7 is a schematic diagram of a portion of the memory of the targetplatform. As shown in FIG. 7, the subject program 17 is allocated asubject program area 175 in the target memory 18, alongside othercomponents such as the translator code 19 and the target code 21. Thissubject program area 175 typically comprises a linear range of virtualaddresses, which map to one or more sets of physical storage locationsas will be familiar to persons skilled in the art. The modified programcounter PC_S′ passed to the subject exception handler 170 suitably liesoutside this subject program area 175. Further, the subject program mayhave one or more dynamically allocated memory areas 176 such as forworking storage, and the modified program counter PC_S′ also suitablyfalls outside the dynamically allocated subject areas 176.

FIG. 8 is a schematic flow diagram illustrating a method of exceptionhandling for native bound code as employed by example embodiments of thepresent invention.

As discussed above, an exception occurs during execution of native boundcode (step 801). A current execution state is saved (step 802),reflecting execution of the native bound code on the target platform(target state T′). Also, a subject state (S′) is created (step 803)reflecting an emulated point of execution on the subject platform, as ifthe exception had occurred whilst executing subject code on the subjectplatform. In particular, the created subject state S′ includes a stackpointer SP_S′ to the subject stack, where the target state T′ isconveniently stored. Also, the subject state S′ includes a speciallymodified program counter PC_S′ as discussed above. The exception ishandled with reference to the created subject state S′ (step 804). Thesubject exception handler 170 will include instructions which determine(step 805) whether or not to resume execution at the point where theexception occurred (i.e. return to the previous point of execution,which in this case lies in the native bound code). In somecircumstances, execution of the subject program is halted, or controlpasses to a different portion of the program (step 809). However, whereit is determined to resume execution at the point where the exceptionoccurred, execution is resumed using the created subject state S′ (step806) which links to the saved target state T′ (step 807) to resumeexecution of the native bound code (step 808).

In summary, the mechanisms and embodiments described herein have manyadvantages, including that exceptions occurring during native bound codeare handled reliably and efficiently. In the example embodiments,storing the target state T′ linked by the subject state S′ allowsexecution of bound native code 28 to be resumed after handling anexception. Also, by modifying the subject program counter in the mannerdescribed above, the subject exception handler 170 can return control tothe native code 28 by directly or indirectly performing the recoveryfunction 171 which loads the stored target state T′. Further, using thesubject stack 81 for execution of the native code 28 maintains thesubject stack in good order and allows resources to be releasedefficiently. These and other features and advantages will be apparent tothe skilled person from the above description and/or by practicing thedescribed embodiments of the present invention.

Although a few example embodiments have been shown and described, itwill be appreciated by those skilled in the art that various changes andmodifications might be made without departing from the scope of theinvention, as defined in the appended claims.

Attention is directed to all papers and documents which are filedconcurrently with or previous to this specification in connection withthis application and which are open to public inspection with thisspecification, and the contents of all such papers and documents areincorporated herein by reference.

All of the features disclosed in this specification (including anyaccompanying claims, abstract and drawings), and/or all of the steps ofany method or process so disclosed, may be combined in any combination,except combinations where at least some of such features and/or stepsare mutually exclusive.

Each feature disclosed in this specification (including any accompanyingclaims, abstract and drawings) may be replaced by alternative featuresserving the same, equivalent or similar purpose, unless expressly statedotherwise. Thus, unless expressly stated otherwise, each featuredisclosed is one example only of a generic series of equivalent orsimilar features.

The invention is not restricted to the details of the foregoingembodiment(s). The invention extends to any novel one, or any novelcombination, of the features disclosed in this specification (includingany accompanying claims, abstract and drawings), or to any novel one, orany novel combination, of the steps of any method or process sodisclosed.

1. A method of handling an exception, comprising the steps of: (a)performing program code conversion to convert subject code executable bya subject computing architecture into target code executable by a targetcomputing architecture; (b) executing a portion of native code which isnative to the target computing architecture in substitution fortranslating a portion of the subject code into the target code; (c) inresponse to an exception arising during execution of the portion ofnative code, performing the steps of: (i) saving a target state whichrepresents a current point of execution in the target computingarchitecture with respect to the native code portion; (ii) generating asubject state which represents an emulated point of execution in thesubject computing architecture; and (iii) handling the exception withreference to the subject state; and (d) resuming execution from theexception by using the subject state to restore the target state, andthen using the target state to resume execution of the native codeportion.
 2. The method of claim 1, wherein the subject state comprises alink to the target state.
 3. The method of claim 1, wherein the step (d)comprises executing a recovery routine to restore the target state. 4.The method of claim 1, wherein the subject state includes a modifiedsubject program counter and the method further comprises passingexecution control to the modified subject program counter therebyexecuting a recovery routine to load the target state and returnexecution control to the portion of native code.
 5. The method of claim4, wherein the modified subject program counter has a predeterminedvalue and the method further comprises detecting the predetermined valueand redirecting execution control to execute the recovery routine. 6.The method of claim 1, wherein the subject state includes a modifiedsubject program counter, and the method further comprises providing areserved location to be treated as a portion of the subject code at anaddress identified by the modified subject program counter.
 7. Themethod of claim 6, wherein the reserved location contains subject codeinstructions and the method comprises translating and executing thesubject code instructions as target code, thereby to recover the targetstate and resume execution of the portion of native code.
 8. The methodof claim 6, wherein the reserved location contains special caseinstructions which do not fall within an instruction set architecture ofthe subject computing architecture, and the method comprises detectingthe special case instructions and in response executing a recoveryroutine to recover the saved target state and resume execution of theportion of native code.
 9. The method of claim 6, comprising using themodified subject program counter as a return address after handling theexception, when attempting to restart execution of the subject code at apoint where the exception occurred, such that execution control passesto the reserved location.
 10. The method of claim 1, further comprisingthe steps of: converting a caller portion of the subject code intotarget code and forming a first subject state including at least asubject program counter; calling the portion of native code from thecaller portion of target code; and copying and modifying the firstsubject state to form the subject state.
 11. The method of claim 1,further comprising providing a subject stack data structure in a memoryof in the target computing architecture for emulating execution of thesubject code on the subject computing architecture, and executing theportion of native code using the subject stack.
 12. The method of claim1, further comprising providing a subject stack in the target computingarchitecture for emulating execution of the subject code on the subjectcomputing architecture, and storing the subject state on the subjectstack prior to handling the exception whereby the stored subject stateis available from the subject stack after handling the exception. 13.The method of claim 1, further comprising providing a subject stack inthe target computing architecture for emulating execution of the subjectcode on the subject computing architecture, and saving the target stateon the subject stack prior to handling the exception whereby the targetstate is available from the subject stack after handling the exception.14. The method of claim 13, wherein the step of saving the target statecomprises saving values of a set of registers of a target processor ofthe target computing architecture onto the subject stack, and the methodfurther comprises restoring the target state including loading the savedvalues from the subject stack into the set of registers.
 15. The methodof claim 1, further comprising handling the exception and determining toresume execution of the subject code at a point where the exceptionoccurred using the subject state, or to resume execution of the subjectprogram at another point in the subject code by altering a subjectprogram counter in the subject state.
 16. A method of handling anexception, comprising the steps of: converting subject code executableby a subject computing platform into target code executable by a targetcomputing platform, including converting a caller portion of subjectcode into a caller portion of target code; executing the caller portionof target code thereby generating on the target computing platform afirst target state relating to execution of the target code andemulating a first subject state representing execution of the callerportion of subject code on the subject computing platform; calling fromthe caller portion of target code to a portion of native code which isnative to the target computing platform; executing the portion of nativecode on the target computing platform thereby generating a second targetstate and, where an exception occurs during execution of the portion ofnative code, saving the second target state and generating a secondsubject state based on the first subject state wherein the secondsubject state comprises a link to the second target state; and handlingthe exception with reference to the second subject state and using thesecond subject state to link to the second target state to therebyresume execution in the portion of native 7 code.
 17. The method ofclaim 16, further comprising the step of executing of a recovery routineto restore the second target state when resuming execution from theexception.
 18. The method of claim 16, wherein the second subject statecomprises a modified subject program counter and the method furthercomprises passing execution control to the modified subject programcounter, loading a recovery routine to load the saved second targetstate, and thereby returning execution control to the portion of nativecode.
 19. The method of claim 18, wherein the modified subject programcounter has a predetermined value and the method further comprisesdetecting the predetermined value and redirecting execution control tothe recovery routine.
 20. The method of claim 16, wherein the secondsubject state comprises a modified subject program counter, and themethod further comprises providing a reserved location treated as aportion of the subject code at an address identified by the modifiedsubject program counter.
 21. The method of claim 20, wherein thereserved location contains subject code instructions and the methodcomprises converting and executing the subject code instructions astarget code thereby causing recovery of the saved target state wherebythe portion of native code resumes execution.
 22. The method of claim20, wherein the reserved location contains special case instructionswhich do not fall within an instruction set architecture of the subjectcomputing platform, and the method comprises detecting the special caseinstructions and in response executing a recovery routine to recover thesaved second target state thereby enable execution of the portion ofnative code to resume.
 23. The method of claim 20, comprising using themodified subject program counter as a return address after handling theexception, when attempting to restart execution at a point where theexception occurred, whereby execution control passes to the reservedlocation.
 24. The method of claim 16, wherein the first subject statecomprises at least a subject program counter, and wherein generating thesecond subject state comprises copying the first subject state to formthe subject state and modifying the subject program counter to amodified value.
 25. The method of claim 16, further comprising providinga subject stack data structure in the target computing platform foremulating execution of the subject code on the subject computingplatform, and executing the portion of native code with reference to thesubject stack.
 26. The method of claim 16, further comprising providinga subject stack in the target computing platform for emulating executionof the subject code on the subject computing platform, and storing atleast the second subject state on the subject stack prior to handlingthe exception, such that the stored second subject state is availablefrom the subject stack after handling the exception.
 27. The method ofclaim 16, further comprising providing a subject stack in the targetcomputing platform for emulating execution of the subject code on thesubject computing platform, and saving at least the second target stateon the subject stack prior to handling the exception, such that thesaved second target state is available from the subject stack afterhandling the exception.
 28. The method of claim 27, wherein the step ofsaving the second target state comprises saving values of a set oftarget registers of a target processor of the target computing platformonto the subject stack, and the method further comprises restoring thesecond target state including loading the saved values from the subjectstack into the set of target registers.
 29. The method of claim 16,further comprising handling the exception and determining to resumeexecution at a point where the exception occurred using the subjectstate, or to resume execution of the subject program at another point inthe subject code by altering a subject program counter in the subjectstate.
 30. A target computing platform arranged to handle exceptionsduring binding to native code, comprising: a translator unit arranged totranslate subject code executable by a subject computing platform intotarget code executable by the target computing platform, and arranged tosubstitute a portion of native code which is native to the targetcomputing platform instead of translating a portion of the subject codeinto the target code; an execution unit arranged to execute the targetcode and the native code, and to raise an exception signal when anexception occurs; an exception handler unit arranged to detect theexception signal raised by the execution unit during execution of thenative code, cause the saving of a target state which represents acurrent point of execution in the execution unit for the native code,provide a subject state which represents an emulated point of executionin the subject computing platform, and handle the exception withreference to the subject state; and a recovery unit arranged to restorethe saved target state by linking from the subject state and therebyresume execution of the native code in the execution unit using thesaved target state.
 31. A translator apparatus arranged to handleexceptions during binding to native code, comprising: a translator unitarranged to convert subject code executable by a subject computingplatform into target code executable by a target computing platform, andarranged to cause the target computing platform to execute a portion ofnative code which is native to the target computing platform insubstitution for converting a portion of the subject code into thetarget code, and further wherein the translator unit is arranged toconvert caller subject code into caller target code for execution by thetarget computing platform to provide a first target state and a firstsubject state and to cause at least the first subject state to be savedwhen calling into a portion of the native code from the caller targetcode; an exception handler unit arranged to detect an exception signalraised during execution of the native code, cause the saving of a secondtarget state which represents a current point of execution in the targetcomputing platform for the native code, and provide a second subjectstate, wherein the second subject state comprises a link to the secondtarget state; a subject exception handler unit arranged to handle theexception with reference to the second subject state; and a recoveryunit arranged to cause the target computing platform to resume executionof the native code by linking to the second target state from the secondsubject state.
 32. A computer-readable medium having recorded thereoninstructions implementable by a computer to perform a method of handlingan exception, comprising the steps of: (a) performing program codeconversion to convert subject code executable by a subject computingarchitecture into target code executable by a target computingarchitecture; (b) executing a portion of native code which is native tothe target computing architecture in substitution for translating aportion of the subject code into the target code; (c) in response to anexception arising during execution of the portion of native code,performing the steps of: (i) saving a target state which represents acurrent point of execution in the target computing architecture withrespect to the native code portion; (ii) generating a subject statewhich represents an emulated point of execution in the subject computingarchitecture; and (iii) handling the exception with reference to thesubject state; and (d) resuming execution from the exception by usingthe subject state to restore the target state, and then using the targetstate to resume execution of the native code portion.
 33. Acomputer-readable medium having recorded thereon instructionsimplementable by a computer to perform a method of handling anexception, comprising the steps of: converting subject code executableby a subject computing platform into target code executable by a targetcomputing platform, including converting a caller portion of subjectcode into a caller portion of target code; executing the caller portionof target code thereby generating on the target computing platform afirst target state relating to execution of the target code andemulating a first subject state representing execution of the callerportion of subject code on the subject computing platform; calling fromthe caller portion of target code to a portion of native code which isnative to the target computing platform; executing the portion of nativecode on the target computing platform thereby generating a second targetstate and, where an exception occurs during execution of the portion ofnative code, saving the second target state and generating a secondsubject state based on the first subject state wherein the secondsubject state comprises a link to the second target state; and handlingthe exception with reference to the second subject state and using thesecond subject state to link to the second target state to therebyresume execution in the portion of native code.